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1. INTRODUCTION 

Software-defined networking (SDN) introduce more flexible and scalable services [1, 2]. Security is one 
of the main topics behind SDN [3], unfortunately, with separate control and data place, the centralized 
architecture is vulnerable to attacks that target to destroy or disrupt the central SDN unit [4, 5]. 
SDN controller is the brain of the network but once it is down or inaccessible all new requests will not be 
processed. A successful distributed denial of service (DDoS) type of attack may successfully exhaust 
the CPU and memory of the controller. Once the goal is achieved, all new legitime and non-legitim requests 
will be blocked by the SDN controller. 

SDN architecture consists of three main layers and they are as follows: Infrastructure, control and 
application layer as shown in Figure | [2]. The application layer is responsible for applications and 
communicates with the SDN controller via REST API. The SDN controller translates the requirements 
provided from the application layer to instructions and configurations on the infrastructure layer. There are 
several types of DoS attacks that can target each of these three layers. This article is focused on the control 
layer DDoS mitigation. OpenFlow [6] protocol instructs the switches to send Packet_in events to 
the controller when the requests to the destination are not part of their local flow tables as shown 
in Figure 2. 

The controller decides on how to process the request. If the decision is to approve and process 
the request, the controller instructs the switch which creates a flow entry in its flow table. Each unique 
request creates two flow entries in each OpenFlow switch on the way of the chosen path. Software-defined 
networks have less latency and jitter than traditional networks [7] so during DDoS attack, all requests 


Journal homepage: http://beei.org 


are from spoofed IP addresses and each of them is asking the controller to take a proper decision. Due to 
the huge number of unique requests, all OpenFlow enabled switches may reach the limit of their flow tables 
fast. OpenFlow switches have a feature to send to the controller the whole packet instead of the header only 
which may lead to overload the management interfaces between the switch and SDN controller. 
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Figure 1. SDN controller layers model Figure 2. OpenFlow process 


There are many proposed solutions for DDoS mitigation [8] and detection [9] but if a DDoS attack 
is not mitigated before it reaches the SDN controller, the control layer might be affected. Successful DDoS 
protection is a solution provided by the Internet Service Provider and all non-legitim packets are filtered 
before they hit the client’s network. Mostly used DDoS attacks are volumetric UDP/ICMP amplifications 
and flood type of attacks. They overload the internet traffic channels and interrupt legitimate traffic [10]. 
The target of such attacks is corporate networks, data centers with web hosting services, blockchain 
networks [11] and even campus networks [12]. State exclusion TCP and application-layer attacks may mostly 
affect the control layer. Some controllers have their protection mechanisms and they stop processing traffic 
when a threshold is reached. This is good for the controller, but the real effect is that the newly arrived 
legitim request is not processed as well. 

This article is organized as follows. SDN architecture and DDoS effect over it are reviewed in 
section 2. Related works are discussed in section 3. Section 4 introduces the experimental setup, 
an explanation about how the DDoS attack is a simulated and different type of topologies. A comparison 
between them is reviewed and analyzed. The article is concluded in section 5. 


2. RELATED WORKS 

Our previous work was focused on studying the DDoS attack effect of bandwidth utilization over 
the SDN controller southbound channel and CPU utilization on SDN controller [13]. The main goal of this 
paper is to measure the effect when multiple requests for different sources are entering the networks and how 
the southbound channel is affected. We did two experiments with single switch topology and tree topology 
with multiple switches but the same number of hosts and then we compared the results for these two 
topologies. The hosts represent the number of unique sources that are generating new connections that trigger 
packet_in events. The third experiment was focused on how fast the controller’s threshold will be reached by 
increasing the count of hosts. In this work, the same lab environment is used, but this time we were looking 
for optimal topology and count of switches part of the network. Increasing the number of switches with 
the same number of hosts the delay of the controller’s response is increasing as well. With switch count 
increase the network becomes more reliable and high availability with more clients/users that can 
communicate faster with each other. With the growing number of Openflow switches within the networks, 
the control plane is a potential bottleneck. The problem with one centralized controller can be easily solved 
with logically centralized but physically distributed architecture with several controllers [14]. Such architecture can 
increase the control plane scalability of the networks. Unfortunately, such architecture has drawbacks if 
the switches are statically configured as the network flow and traffic patterns are unpredictable and at some 
time of the day or week, one of the controllers can be fully loaded while the rest may have a much smaller 
load or unutilized. With statically mapped switches the DDoS attack will affect only the controllers that 
are facing the incoming requests so this would not solve the problem. 
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There are several solutions for dynamically rebalancing architecture with multiple controllers which 
can help with scalability on the control plan level. The JGroups [15] proposal is splitting the network into 
several logical groups and each group is controlled by one active/standby controller cluster. With switch 
migration, the load can be shifted from one cluster to another to even load balancing to be achieved. 
This approach avoids a single point of failure because of the supports controller’s failover without 
disruptions. ElastiCon [16] is a solution that presents dynamically increase or decrease of SDN controllers 
based on load estimation of control plane usage. ElastiCon architecture manipulates the control plane without 
any interruption as well. Both solutions use a role-request message of OpenFlow protocol for their purposes. 
In the case of DDoS attack, JP Groupe architecture can be used for mitigation but it will work only if 
the attack is not so big. Most of the enterprise customers have at least two active/active or active/standby 
Internet service providers circuits so during the attack the ingress traffic will hit only one or two switches and 
respectively one or two controllers. 


3. RESEARCH METHOD 

The experimental setup is presented in Figure 3. Two virtual machines (VMs) with the following 
characteristics CPU: Intel 15 6300 2.4 GHz with 4 GB of RAM are connected via a virtual switch. On the first 
VM of the most popular SDN controllers, the Floodlight OpenFlow controller is installed. On the second 
VM, Mininet OpenFlow [17, 18] switch emulator is installed. OpenFlow 1.3 version is used 
for a communication protocol between the controller and Mininet switch. The connection between VMs 
is via the VMware virtual switch. With a Mininet simulator, a different number of hosts have been created. 
With the additional script, these hosts are forced to generate traffic targeting other hosts from the network. 
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Figure 3. OpenFlow process 


These unique requests generate unique connections that must be processed by the SDN controller, 
so this simulates the effect of a DDoS attack. Depends on the number of hosts the unique requests can be up 
to 100 requests per second. To load balance the traffic between Mininet simulated switches and SDN 
controllers a load balancer is configured to load share the southbound connections. The load balancer uses a 
round-robin algorithm to load-balance all connections equally between controllers. Each switch should 
communicate with the same controller whenever a new request is triggered so source address persistence is 
used for the persistence algorithm. 

Tests were done on two types of topologies. The first one Figure 4 is the liner and one switch is 
connected to the other two only. Each switch has at least one host connected as well. The path from the first 
switch to the last one is passing through all switches of the network, so the controller must configure all 
switches for each traffic flow request. If we compare the first topology with existing productive topologies it 
is closer to small office (SOHO) topology where only few end hosts are connected to the switches and each 
switch is connected to the other one. 

The second type Figure 5 of topology is more mesh than linear. Depends of the settings each switch 
is connected to several others so the traffic flow has more redundancy paths and if we try to compare the 
traffic flow of this topology with the first one, when the first host needs to communicate with the last host 
the packets will not go through all switches of the network, but the controller will choose the shortest path 
based on SPF algorithm. This means that the controller needs more CPU and resources for first type topology 
comparing with the second one. Second type of topology is more mesh it is looks closer to spine-leaf 
topologies where each leaf switch is connected to every spine switch [19, 20]. The main advantage is that 
each switch has several links connected to the other switches which provide more redundant paths. Spine-leaf 
topologies are more cost effective and provide better performance comparing with other topologies [19]. 
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Figure 4. First type topology-linear Figure 5. Second type topology-mesh 


4. RESULTS AND DISCUSSION 

We did several experiments with both topologies and a different number of controllers. 
Both topologies are tested under the same type of attack and all controllers have the same CPU and memory 
resources. We have reviewed similar researches [21, 22] with similar tests with Onos controllers [23], but our 
results are little bit different because of the size of the network and type of the controller-Floodlight [24, 25]. 
In these researches the networks have only 3 switches and one controller which is not so close to real 
productive networks. In our experiments we simulate networks starting from 3 up to 80 switches and the 
simulation of volumetric DDoS attack is closer to real productive networks which explain the difference in 
results. When the controller takes decisions in bigger networks it should calculate and instruct more switches 
which takes allocates more CPU/memory resources. 


4.1. The first type of topology experiment 

In Figure 6 results for the first type topology can be reviewed. The same types of tests are done with 
one, two and three controllers. We can see that with one controller the optimal topology contains only 
22 switches. If more switches are added and similar DDoS attack is triggered the SDN controller win start 
rejecting new requests so neither the legitim nor malicious traffic will be processed, and the attack will be 
successful. If the second active SDN controller is added the results show that the optimal topology 
is 48 switches. Once 3 controllers are activated the maximum count of switches that can handle such attack 
is 70. The result shows that that first topology reacts similarly during the attack. With increasing the active 
controllers, the total cost of network infrastructure is increasing as well. It is recommended behind each 
active controller one standby to be added in a cluster mode for high availability. In case that 3 active 
controllers are needed some low budget, designs recommend only 2 standby controllers to be deployed 
to save some cost. 
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Figure 6. First type topology 
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4.2. The second type of topology experiment 

The second experiment is similar to the first one, but the topology is different. In Figure 7 the results 
of mesh topology can be seen. The second topology looks more stable and does not consume such resources 
comparing with the first one. If only one controller is active and same attack is triggered to the network, 
the topology shows that 26 switches can be active until the SDN controller decides to block all new requests. 
Once the second active controller is added to the networks it can manage up to 50 switches during 
a simulated attack. When three controllers are active the number of switches is increased up to 78. 

The second topology looks more stable and does not consume such resources comparing with 
the first one. If only one controller is active and same attack is triggered to the network, the topology shows 
that 26 switches can be active until the SDN controller decides to block all new requests. Once the second 
active controller is added to the networks it can manage up to 50 switches during a simulated attack. 
When three controllers are active the number of switches is increased up to 78. 
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Figure 7. Second type topology-mesh 


4.3. Compare both topologies with one and three controllers 
The next two figures-Figure 8 and 9 show the comparison between both topologies and based on 
that we can conclude which of these two is more stable and resistant to DDoS attack. 
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Figure 8. Comparison between both topologies with one controller 
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Figure 9. Comparison between both topologies with three controllers 


CONCLUSION 
This paper has presented an optimal network topology and size to handle distributed denial of 


service attack without management channel bandwidth exhaustion or run out of SDN controller CPU and 
memory. It can be concluded that the second type of topology is more resistant to DDoS attack. When only 
one controller is active the second topology looks more stable than the first topology type. If three controllers 
are activated to process new requests the results show that the difference between both topologies is much 
smaller but still the second type topology is more stable. We can conclude that mesh topologies with more 
links between switches are more resistant to DDoS attacks. In the future, we are planning to do researches 
with different types of controllers-Onos, Floodlight, and Ryu or different OpenFlow versions. 
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